Adopted-entity curation: user-asserted metadata from a new Adopted tab - #266

…toring an unreadable one

Read the stored overlay into runtime data before the platforms are forwarded,
so every adopted entity is born with its curated metadata rather than having it
applied after its first state is written. The field is required rather than
defaulted: a setup path that forgets the load has to fail loudly, because an
empty overlay is indistinguishable from a user who has curated nothing.

Removing the entry forgets the store, as it already forgets the announcement
record. The keys are wire addresses rather than registry ids, so a store left
behind is one the next entry for the same panel would load and apply.

…hedule reload

…e class

developer.md gains a Curation section covering the .storage overlay and its
scope-prefixed keys, validation refusing at save and dropping at construction,
the description helpers that keep both AST guards absolute, the two websocket
commands' zero-registry-writes boundary, and why the reload is the mechanism
rather than a courtesy. The revisable-vs-not table's state_class row moves from
"never set at all" to user-curated only, and the diagnostics section gains the
adopted_curation block's withholding rule.

README.md documents the Adopted tab: what the integration sets versus what is
Home Assistant's own, that saving reloads, the total_increasing and
statistics-class-removal consequences, and that identity never changes.

…tion

# Conflicts:
#	CHANGELOG.md

The Adopted tab no longer offers an icon: it wrote through the same registry
command Core's own entity settings dialog issues, so it was a second place to
set one thing. The field lists in the README and frontend.md drop it and say
where the icon and the area are set instead.

developer.md's validation section gains the datatype half of the device-class
gate, and the reason `declares_a_number` is one predicate rather than two: the
same answer decides whether a reading is parsed as a number and which half of
Core's device-class vocabulary the row is offered.

The condensed Adopted sections left an orphaned </details>, a bullet
with scrambled markup, two sentences split mid-phrase, and two dead
cross-references (#adopted-vendor-readings, and #bess--grid-management
which bess-grid-management.md links to). Restore the BESS heading level
so its four subsections are parented again, and give "the confirmation"
and the reading-vs-control distinction the antecedents their cut
paragraphs used to supply.

Normalize documentation prose to US spelling. The identifier references
`is_modelled` and the normalising test name stay en-GB so they still
name the Python symbols they refer to.

…eases

The lockfile still recorded homeassistant 2026.8.0 and span-panel-api 3.3.0
while pyproject pins 2026.8.3 and 3.4.1, so uv lock --check failed and every
bare uv run re-resolved and left the file dirty.

The span-panel-api path in [tool.uv.sources] is relative to the repository
root, so it arrives from the primary checkout and from a worktree beside it,
and misses from one nested inside the checkout at .claude/worktrees/<name>,
which sits two levels deeper. uv run then cannot build an environment at all,
so pylint, mypy, vulture, both radon hooks and the test suite fail before they
start -- and the first commit from a new worktree is where you find out.

setup-hooks.sh now bridges the gap with a symlink, both ends derived from git
rather than written down, and asks git for the pre-commit hook path rather than
assuming .git/hooks, which a worktree's .git file is not.

check-library-path.py claimed the relative path resolves to the same directory
from every worktree. It does not, and the claim is why this reads as a broken
pin rather than a path-depth problem.